By

文章目录
  1. 1. 控件透明的判断
  2. 2. WebView花屏
  3. 3. bound service

从用户角度讲，Android L算的上有屎以来最棒的Android系统，无论外观，还是性能，android 5都绝对是最高点。相较于它的前辈们，各方面的提升都相当明显。从体验上讲，离iOS距离越来越近了。当然，如果不是操蛋的墙，使得google service除了耗电别无二用的话， 这个距离还可以更小。

然而，不是一切都是美好。比如对于码农来讲，新的系统出来，老的代码就必然就会伴随着一番折腾。下面我们就来挑几个说说。

控件透明的判断

以前显示的好好的头像突然不对了。我们的头像学着ios的风格，都裁剪成了圆形，做法比较简单，重载BitmapDrawable的draw方法，做一些运算即可。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Override
public void draw(Canvas canvas) {
    copyBounds(bounds);
    
    // new layer
    canvas.saveLayer(new RectF(bounds), null, Canvas.ALL_SAVE_FLAG);
    super.draw(canvas); 
    
    // makeup
    paint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.DST_IN));
    canvas.drawBitmap(mask, null, bounds, paint); // mask是一个圆形罩图

    // apply layer
    canvas.restore();
}

在之前，这段简单的代码一直勤勤恳恳的工作，没有出过任何差错。可到了5.0，原本透明的圆形外框变成黑色了。界面刚打开时，还能透过黑色看到后面的luancher背景。开始时以为是硬件加速的原因，把控件由软加速改为了硬件加速，确实，黑框消失了，变正常了，但由于另外一个地方用到了更复杂的剪切和叠加，整个列表滑动变的异常迟滞，只好又改回来。然后我又尝试预先就把图片处理好，创建BitmapDrawable的时候直接赋给它，发现是正常的。后面做调试跟踪，一级级的查下去，突然发现Drawable有个getOpacity方法，这这里返回的居然是PixelFormat.OPAQUE。一想，肯定就是这里了。画到画布上的alpha通道直接被丢弃掉了啊，因为我们传给构造函数的Bitmap是RGB565格式的，默认认为你这个就是没有alpha通道，所以不需要！看看说明，这个方法就是可以重载的。于是，强制返回TRANSLUCENT，OK了。 在自定义Drawable中载入如下代码：

1
2
3
4
@Override
public int getOpacity() {
    return PixelFormat.TRANSLUCENT;
}

WebView花屏

在有scrollview的页面，偶尔发现界面花掉了，有时候是像电视没了信号的麻花，有些地方又是界面画的错乱了，特别是点ActionBar上的返回按钮时，特别容易出现。这他妈真的是完全无处可查啊。最后只好svn一个版本一个版本的回滚，耗费大量时间不停的尝试（因为TMD还是偶现啊！），终于找到了一点点踪迹，自从那个版本在首页某一帧加了一个webview之后，只要那个webview调过loadUrl，后面花屏就必现。但什么原因，还是无从知晓，我们什么都没干啊。这玩意拖了很久，后来某一天看android的硬件加速文档时，突发奇想，不会跟这有关系吧？赶紧去把那个webview的硬件加速给关了，再一跑，真的不出现了。这尼玛，坑爹啊。反正给解决了。过两天给google提bug去。

bound service

偶现有service在后台跑着跑着就挂了，后面再怎么调startService都爬不起来。根据log可以看到，service的宿主进程的Application的onCreate方法已经被调用，有没有跑完待定。但service的onCreate方法却没有调用到。

本来以为这是5.0的坑，后来才发现，原来从4.4就已经有了，原因是系统在停掉service时，状态清理出了问题。具体原因另说吧。

文章目录
  1. 1. 控件透明的判断
  2. 2. WebView花屏
  3. 3. bound service